Skip to main content
Expert Talk
Amakomaya — Aamako Maya Apps Pvt. Ltd.

Digital Public Infrastructure for Health

Status

Digital public infrastructure (DPI) is a policy framing that has consolidated rapidly since about 2023. The general DPI concept is well documented by the UN, the World Bank and national programmes. Health-specific DPI reference architecture is newer, and individual documents range from published guidance to draft and consultation material.

This page separates the two, and marks status where it can be established. Anything marked needs verification should be checked at source before being cited in a specification or tender.

The idea​

DPI treats certain digital capabilities as shared public rails — built once, governed publicly, and reused across sectors — rather than as things each programme builds for itself.

The commonly cited trio:

RailProvidesHealth use
IdentityVerifying who someone isLinking a person's records across facilities and time
PaymentsMoving moneyInsurance reimbursement, provider payment, conditional cash transfers, CHW stipends
Data exchangeConsented data sharing between organisationsHealth information exchange itself

Supporting layers: consent management, digital signatures, notification and messaging, registries, and open APIs with a trust framework.

The argument for health is straightforward. A health ministry that builds its own identity system, its own payment integration and its own consent service is duplicating national infrastructure at greater cost and lower quality — and producing a health silo at exactly the moment the goal is to remove silos.

The relationship to health architecture​

DPI is not an alternative to OpenHIE or to a national digital health architecture. It sits underneath them.

   ┌────────────────────────────────────────────────────┐
   │  Health applications                               │
   │   EMR · HMIS · CHW app · LMIS · claims             │
   ├────────────────────────────────────────────────────┤
   │  Health-specific shared services                   │
   │   Client registry · facility registry · HWR ·      │
   │   terminology · shared health record · IOL         │
   ├────────────────────────────────────────────────────┤
   │  Digital public infrastructure                     │
   │   Foundational ID · payments · data exchange ·     │
   │   consent · signatures · notification              │
   ├────────────────────────────────────────────────────┤
   │  Connectivity, hosting, cloud                      │
   └────────────────────────────────────────────────────┘

The health layer still exists and is still health-specific. What changes is that identity, consent and payments are consumed from national services rather than rebuilt.

The design decisions this forces​

Foundational identity and health identity​

The central question, treated at length in registries.

Using the national ID directly gives excellent matching where coverage is good, and excludes everyone without one — typically undocumented, displaced, newborn and marginalised populations, who are disproportionately the people health systems most need to reach.

The workable pattern is usually a distinct health identifier, cross-referenced to the foundational ID where one exists, with a defined process for people who have none. That preserves both linkage quality and universal access, and keeps health identity under health governance.

Linkage risk​

Once health data is keyed to the national identity used for tax, policing, welfare and travel, linkage becomes trivial for anyone with access to more than one system. This is a benefit for continuity of care and a serious risk for people whose health information could be used against them.

Mitigations are architectural and legal: sector-specific pseudonymous identifiers, purpose limitation enforced technically rather than by policy alone, and audit of cross-sector queries. These decisions belong in the architecture, and once made are extremely hard to reverse.

Governance dependency​

Consuming national infrastructure means depending on another agency's availability, roadmap, security posture and policy. That dependency needs an explicit service agreement, an escalation path, and a stated fallback for when the service is unavailable — an identity outage that blocks patient registration is a clinical incident.

DPI consent frameworks are typically designed around financial and administrative data. Health data has particular requirements: emergency access without consent, break-glass, category-based sensitivity, and delegation for minors and people lacking capacity. See consent and trust.

Assess whether a national consent service can express these before adopting it. If it cannot, a health-specific consent service layered on national authentication is the usual resolution.

Sources​

General DPI — established​

SourceStatus
UN Development Programme, DPI resources — https://www.undp.org/digital/digital-public-infrastructurePublished
World Bank, Identification for Development (ID4D) — https://id4d.worldbank.org/Published
Digital Public Goods Alliance registry — https://digitalpublicgoods.net/registry/Published, maintained
Modular Open Source Identity Platform (MOSIP) — https://mosip.io/Active open-source project (Tier 2)
X-Road (data exchange layer) — https://x-road.global/Active open-source project (Tier 2)

Health-specific DPI — emerging​

WHO and ITU have both engaged with DPI for health, and WHO's Digital Health Platform Handbook predates the DPI vocabulary while describing much the same shared-services idea.

A specific WHO/ITU DPI-H reference architecture is frequently referred to in this space. Needs verification: confirm the current publication status, edition and canonical URL on https://www.who.int/publications and https://www.itu.int/ before citing it as a normative reference. Do not describe a draft or consultation document as a standard.

The general rule for this whole area: cite the specific document and its date, not "the DPI-H architecture".

What is genuinely settled, and what is not​

Settled enough to design against:

  • Shared identity, payments and data exchange reduce duplication, and health benefits from consuming rather than rebuilding them
  • Foundational identity coverage gaps are a health equity problem that must be designed around explicitly
  • Cross-sector linkage creates privacy risk requiring architectural mitigation
  • Health-specific services (registries, terminology, clinical exchange) remain necessary regardless

Not settled:

  • A canonical health DPI reference architecture with agreed component names
  • How health consent maps onto general-purpose consent frameworks
  • Whether health should hold its own identity registry or consume the national one — practice varies and both are defensible
  • Governance models for cross-sector data use

Design for the settled parts. Record the unsettled ones as architecture decisions with the reasoning, so they can be revisited when the guidance firms up.

References​

Last verified: 2026-08-24.

Last updated on